1. Field of the Invention
This invention relates to a video and audio data presentation interface.
2. Description of Related Art
Known computer systems, particularly personal computer systems known as "PC"s, often have coupled peripheral devices that are able to perform some special function. For example, a peripheral device may be coupled to a computer system for presenting video or audio to an operator, such as by displaying pictures or producing sounds for the operator to view and hear. It is generally desirable to place these peripheral devices under the control of a central processing unit (CPU). Particularly, it is generally desirable to control the operation of these peripheral devices from an application program executing on the CPU.
One known method for controlling a peripheral device from an application program is use of a "driver" program. A driver program may be installed with an operating system for the CPU (it may be installed with installation of the operating system, or it may be added later), and may be responsive to a designated interrupt. The application program may execute the designated interrupt to cause the driver program to operate, and may pass arguments, such as control signals or data, to the driver program for its use. The driver program may then control the peripheral device directly.
While this method achieves the purpose of controlling the peripheral device, it has the drawback that two or more driver programs may attempt to use the same designated interrupt. This problem has sometimes been addressed by "chaining", in which the operating system may first assign the interrupt to the driver program that was most recently installed. If this driver program does not recognize the function which the application calls on it to perform, it may cause the operating system to select the driver program that was next-most-recently installed. Chaining may be repeated until some driver program responds to the interrupt, or until an error is returned to the application program.
Chaining is subject to drawbacks. First, if the chain of driver programs that must be selected in turn is too long, response to the application program will be slow. This can be a particularly serious problem in the case of presentation of video and audio data. Slow response may cause the presentation to vary significantly from a realistic presentation.
Second, a chain of driver programs, each attempting to respond to the same designated interrupt, has been found to be prone to error. A relatively innocuous programming error in the operating system, or a relatively minor ambiguity in the arguments used to call upon the driver program, can cause the wrong driver program to be selected. When the wrong driver program is selected, results for the application program are generally unpredictable at best, and catastrophic at worst.
Accordingly, it would be desirable to use a limited number of designated interrupts while avoiding the drawbacks of chaining.
Another drawback of the prior art is related to presentation of video and audio data. Generally, a first peripheral device may be used for video display, while a second peripheral device may be used for audio presentation. Accordingly, different driver programs may be used to control the different devices. However, commonly an application program seeks to present video and audio in synchrony, and must thus attempt to coordinate its commands to different driver programs to achieve that result.
Although some known drivers provide commands for synchronizing data streams, the application program is still generally required to call upon the driver program for each data stream separately. This can increase the complexity of the application program, particularly where there are a multitude of commands to be issued to the driver program. For example, in presentation of video and audio data, there may be commands for "FAST FORWARD", "PLAY", "PAUSE", "REWIND", and "STOP". It would be advantageous if a group of data streams that are to be synchronized could be treated by the application program as a single data stream, so that only a single command to the driver program would be required to manipulate the entire group.
Another drawback of the prior art is that application programs (or at least their programmers) are generally required to comprehend the nature of the peripheral device to make full use of the driver program's commands. For example, if the application program seeks to display both video data and graphics on a single display, it must generally comprise a fair amount of knowledge about how the peripheral device will respond to commands to do so. It would be advantageous if the driver program would handle this for the application program. This would simplify application programs and allow the driver program to use information about the nature of the video and audio peripheral devices, which would otherwise be easy for the application program to mistake.
Another drawback of the prior art is that application programs may desire to provide video or audio data for presentation, but this is not well supported by prior art. For example, the application program may generate the video or audio data itself, may generate the video or audio data in response to data it retrieves from a file, or may retrieve video or audio data from another device (such as a video camera, an MPEG capture device, or a communication device, such as one coupled to a modem or to a T1 communication line). Known interfaces for presentation of video and audio data do not provide operations to make such operation convenient.
Accordingly, it is an object of this invention to provide an improved method for presentation of video and audio data.